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The Prototype System Description Language (PSDL) is a 
language used exclusively for designing and executing rapid 
prototypes. This thesis is directed at developing a model for 
automatically merging two different versions of a PSDL 
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I. INTRODUCTION 


Software Development is an ever-increasing and complex 
industry. As hardware technology gains sophistication, so 
must the software that drives it. In the 1960's, IBM 
developed OS/360. It has been reported that it took 5000 
person-years to develop and document that system.[Ref. 1] 

Since then, hardware has become even more complex. It has 
been said that the software needed to operate the Strategic 
Defense Initiative Systems will far exceed ten million lines 
of code. [Ref. 2] With software systems that sophisticated, 
it is easy to see that current software development methods 
are not adequate to ensure their reliability. To meet this 
challenge, automated software development methods must be 
developed which will increase reliability far beyond what it 
is today. 

Another factor in the need for automated software 
development methods is the inability of most customers to 
precisely state their needs in the early stages of a system's 
life-cycle. This emphasizes the need for getting the customer 
more involved in the early stages of software development, and 
a method for providing the customer with a more accurate 
feeling about what the software system will do when it is 
finished as early as possible. To do this, there must be an 
easy way for making changes to software systems throughout the 
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system lifetime, from the earliest stages of conceptual design 
through system retirement. This, in turn, means that 
software must be developed with evolution in mind. 

A. SOFTWARE MAINTENANCE 

Maintenance can be defined as modification to a software 
product after delivery to correct faults, improve performance 
or other attributes, or adapt it to a changec. environment. 
[Ref. 3] This mindset about maintenance being done only after 
the system is delivered is the traditional notion, and it is 
one of the reasons maintenance is so hard. Designers using 
that mentality were not forced to design their code in a way 
that made making changes easy. According to [Ref. 3], the 
average system in use in 1987 was three to four years old and 
consisted of approximately 55 separate programs and 23,000 
different source statements. Maintenance on these systems is 
hard because most of them were not well documented, when they 
were designed, and the people who built them are no longer 
available to maintain them. This means that a massive effort 
is needed to figure out how to change some of them. A 
different mindset is needed from the first stages of 
conceptual design. 

We prefer to think of software evolution as any 
modification made to a software product throughout its life- 
cycle. Consequently, software should be designed with 
evolution as a primary consideration. Some of the factors 
which can facilitate evolution are: 
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1. Modularity - Modules should be designed to be as self- 
sufficient as possible. 

2. Readability - Structured programming techniques should 
be used whenever possible to compensate for a wide variety 
of programming styles. 

3. Documentation - Design decisions as well as code should 
be well documented and the documentation should be 
maintained throughout the life of the system. 

4. Simplicity - Designs should be made as simple as 
possible. The more complex a system is, the harder it 
becomes to understand. 

These factors are not sufficient to ensure system 
maintainability, but they are necessary. As we mentioned 
earlier, software systems in the future are going to be much 
larger and more complex. Traditional methods for design and 
maintenance will not be sufficient. More innovative ways to 
handle these problems will be necessary. 

1. Model for Software Manufacture 

Software manufacture can be defined as the combining 
of primitive components of a software system, through a 
sequence of derivations, into one or more software products. 
It is software manufacture which establishes the relationships 
between the components of a software system and the primitives 
from which they were derived. Within the software 

manufacturing process, one of the most difficult problems 
involves dealing with change. 

Changes are inevitable, and they can come in several 
different ways. They can be "pre-planned", as there may not 
have been enough cime to incorporate all of the proposed 
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capabilities into a system in the time provided, they can be 
"corrective", if a bug is discovered in the system, or they 
can be "opportunistic", when it is discovered that a change 
can easily be made to the original design which will improve 
it in some way. When changes are made, problems can develop 
if all the components of the system affected by the change are 
not modified to deal with the change. As systems get larg< r 
and more sophisticated, these problems are amplified. [Ref. 4] 

In [Ref. 4], a model is presented for managing the 
software manufacturing process. It is designed to represent 
software systems at a very low level, concentrating on what 
the system does and how its components depend on one another. 
The model has two parts, the configuration, C, and a set of 
difference predicates, which serve to insure consistent change 
incorporation. 

The configuration, consists of a bipartite 
Directed Acyclic Graph (DAG), with components 1 in one set and 
manufacturing steps in the other. Manufacturing steps are 
non-concrete derivations and processes performed on 
components. ^ is a tuple < G, E, L > where G is a DAG, E is 
the subset of £ which contains the export components of the 
system, and L is a labeling function which assigns distinct 
labels to all the nodes in G. 

Components in this model are software components, 
development tools, etc., which exist in the manufacturing 
environment. 




This is a fairly good model. It provides an 
excellent representation of historical data, which is useful 
for managing change information. A problem arises when two 
separate versions of a system have emerged and the merging of 
their capabilities is desired. It also does not provide for 
the propagation of changes throughout a series of different 
versions of a system. Each such update must be made 
individually. Additionally, the graph contains too many 
unnecessary components. A much simpler model which solves 
some of these problems is presented in the next section. 

2. Model For Software Maintenance 

The model for software maintenance contained in 
[Ref. 5] is designed to provide a methodology for integrating 
information about software maintenance activities and 
configuration control. This model assumes the following: 

1. Management controls system changes. 

2. Actual maintenance is performed outside the central 
configuration repository. 

3. Products of the configuration are derived from the 
repository and installed at the production site. 

4. The system configuration remains consistent at all 
times. 

The model is comprised of two major elements, system 
components and maintenance steps. System components are 


5 




defined as immutable and non-re-derivable 2 software objects. 
Maintenance steps are defined as activities which can change 
the configuration of the system. 

The configuration is modelled as a bipartite DAG 
G of components (C nodes) and maintenance steps (M nodes), 
connected by a set of input arcs, I and a set of output arcs, 
0. A sample configuration is shown in Figure 1. Maintenance 
steps are labelled M,, where q is the number of the step, 
using simple enumeration, the input and output sets of M^ are 
labelled 1,^ and 0 Mq , respectively. The following properties 
apply to maintenance steps: 

1. All maintenance steps can have 0 or more inputs, no more 

than one output. VM, | I„ | > 0 & | 0„ | < 1 

2. A maintenance step is empty if and only if it has no 

inputs and no outputs. | I* | =1 0„ | =0 

3. If a maintenance step has at least one input, it must 

have an output. VM, | I„ | * 0 | 0„ | =1 

4. A component cannot be in the input and output sets of 

the same maintenance step. c £ := $ (c £ 1,^) 

5. No one component can be the output of two different 
maintenance steps. Vm w m : £ M, (3c £ C such that 

( (m A , c) £ O & (m y c) £ 0) ) => 

6. There is a set of primitives in the configuration which 
are not outputs of any maintenance step. 

P = {c £ C | " 1 3 m £ M such that (m, c) £ 0} 


2 Non-re-derivable objects are source objects, while re- 
derivable objects are those objects which can be constructed 
by applying some tool, or set of tools, to a set of source 
objects. 
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7. Let D* = (I U O)' be the reflexive transitive closure of 
the union of the input and output relations 1 and 0, then: 

a. One component depends on another if and only if they 
share an edge in D* or they are both primitive components 
and related by an "is-component-of" dependency. 

c i depends on c A ( c L , c } ) £ D* v 

c ir Cj £ P such that is-component-of (c y cj 

b. One maintenance step depends on another if and only if 

they share an edge in D*. m } depends on (m lf m^) £ D* 

c. M e is the set of maintenance steps affected by a 

change to the component c. M a = {m £ H | (c, m) £ D* 



sets spec 

inf 

v2 



Figure 1. Sample Configuration in The Model for Software 
Maintenance. 
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Maintenance steps can be in one of five possible 

states: 

1. Invoked - A requirement for the step has been 
identified, and is under analysis. 

2. Pending - The step has been approved, but assets have 
not been obligated to perform the step. 

3. Implementing - The work is under way. 

4. Completed - The work is finished and the output has been 
returned to the central repository. 

5. Abandoned - The work was stopped before completion or 
the step was never approved. 3 

If a maintenance step is in the implementing state, 
it can be turned back to the pending state, however all work 
done on this maintenance step is lost and must be redone. 
This is impractical, because composite maintenance steps can 
be composed of many smaller maintenance steps, and if a large 
majority of the component steps are completed when the 
composite step is turned back to the pending state, all of 
that work is lost. 

An atomic maintenance step is defined as a single 
change in a single component, its primary input. A component 

c : is a direct descendant of a component Ci if c i €E 0,^ and c A 

is the primary input of M,, or the primary input of is a 
direct descendant of c t . This recursive direct descendance 
relationship defines evolution genealogy sub-graphs of G as 

3 A maintenance step can be abandoned at any time in the 
first three states. Once it is completed, it stays in the 
configuration forever. 







trees with primary inputs and their direct descendants. The 
genealogy trees have the following properties: 


1. All direct descendants of a component c belong to the 
genealogy tree, or sub-tree, which has c as its root. 

2. There exists a unique path between c and any of its 
direct descendants. 

When multiple maintenance steps use a component c as 
their primary input, then parallel genealogies are formed. 
The outputs of these parallel genealogies become different 
versions of a system derived from a common base, c. One of 
the problems with this model is that it provides no way for 
these different versions to be integrated back together to 
capture all of the capabilities of both genealogies in one 
component. This idea provides part of the motivation for this 
thesis. 

B. RAPID PROTOTYPING 

Rapid prototyping is intended to allow the user to get a 
better handle on exactly what his/her requirements are early 
in the conceptual design phase of development. It involves 
the use of automated tools to rapidly create "a concrete 
executable model of selected aspects of a proposed 
system"[Ref. 6] to allow the user to view the model and make 
comments early. The prototype is then rapidly reworked and 
redemonstrated to the user over several iterations until the 
designer and the user have a precise view of what the system 
should do. This process produces a validated set of 
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requirements which become the basis for designing the final 
product.[Ref. 6] The prototype can also become part of the 
final product. In some prototyping methodologies, the 
prototype is an executable shell of the final system, 
containing only a subset of the system's ultimate 
functionality. After the prototype is approved by the 
customer, the holes are filled in and the system is delivered. 
In this approach to rapid prototyping, software systems can be 
delivered incrementally as parts of the system become fully 
operational.[Ref. 6] Figure 2 shows the life-cycle model for 
this prototyping methodology. 

C. COMPUTER AIDED PROTOTYPING SYSTEM 

A set of computer-aided software development tools, 
called the Computer-Aided Prototyping System or CAPS is being 
developed at the Naval Postgraduate School to support 
prototyping of embedded hard real-time systems.[Ref. 6] CAPS 
is designed to reduce the amount of effort required by the 
prototype designer, by providing an integrated set of tools, 
snown in Figure 3, to help design, translate and execute the 
prototypes, along with a language in which to design and 
program the prototypes. 

Computer-aided software development tools are what puts 
the word "rapid" in rapid prototyping. The tools provided for 
in CAPS are divided into three categories: 
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Initial 

Goals 



Figure 2. The Prototyping Life-Cycle Model. 


1. User Interface 

2. Software Database System 

3. Execution Support System 

The user interface contains tools that support the 
prototype designer in designing and programming prototypes. 
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the software database system provides tools which search the 
software base for reusable components, retrieve them, and make 
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them ready for use by the designer in a prototype. The 
execution support system provides tools which translate, 
schedule, and execute the prototype for the designer. The 
prototypes are written in a language designed specifically for 
CAPS, called PSDL. 

D. PROTOTYPE SYSTEM DESCRIPTION LANGUAGE 

PSDL [Ref. 7] is the design based language written 
specifically for CAPS, to provide the designer with a simple 
way to abstractly specify software systems. PSDL places 
strong emphasis on modularity, simplicity, reuse, 
adaptability, abstraction, and requirements tracing. [Ref. 8] 

Modularity is supported through the use of independent 
operators which can only gain access to other operators when 
they are connected via data streams. Operators can represent 
either functions or state machines, depending on whether or 
not they have state variables. Data streams can be one of two 
types, data flow streams or sampled streams. Data flow 
streams operate like FIFO queues of size one. Once a value is 
placed on the stream, it must be read before another value can 
be placed on the stream. Sampled streams operate like memory 
cells of size one. A value is on the stream until it is 
replactd by another value. It is possible, with sampled 
streams, that some values could be read more than once, and 
some may never be read, because they are replaced before the 
stream is sampled. 





Simplicity is gained through the use of a small number of 
language constructs which provide powerful capabilities for 
designing and retrieving prototypes. The grammar for the 
current implementation of the language, located in Appendix A, 
was taken from [Ref. 9] and updated with changes made since 
the publication of that source. 

PSDL prototypes are adaptable through the use of control 
constraints. constraints can be placed on the inputs and 
outputs of operators, as well as timing requirements. 
Reusable software components can be modified slightly, when 
retrieved, to conform to these constraints.[Ref. 8] 

Requirements can be traced in prototypes through the use 
of description constructs which can be written to reflect the 
requirements used in their design. 

PSDL programs are written as a set of PSDL operators and 
data types, containing zero or more of each. PSDL operators 
consist of a specification and an implementation. The 
specification defines the external interfaces of the operator 
through a series of interface declarations, provides timing 
constraints, and describes the functionality of the operator 
through the use of formal and informal descriptions. The 
implementation can either be in PSDL or Ada. Ada 
implementations are Ada software objects which provide the 
functionality required by the operator specification. PSDL 
implementations are data flow diagrams augmented with a set of 
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data stream definitions and a set of control constraints. 
PSDL types also contain a specification and an implementation. 

E. CHANGE PROPAGATION 

One of the things that is lacking in the systems we have 
discussed is the ability to automatically propagate changes 
through multiple versions of the same system. This notion 
becomes important when a fundamental change is made to a base 
system from which multiple different versions have been 
created. Rather than go through each different version 
individually and make the required changes, it would be much 
more efficient to make the change to the base version, and 
then merge that changed base with each of the different 
versions, individually, to automatically incorporate the 
change in each version. This notion could save a tremendous 
amount of time and effort currently spent by system 
maintainers to do this. An example of this idea is shown in 
Figure 4. 

Another view of this ides, portrayed in Figure 5, 
addresses the problem mentioned in the discussion of the Model 
for Software Maintenance, regarding re-combining parallel 
genealogies. If two different modifications of a base program 
contain useful functionality, then automatically integrating 
these modifications into a program which contains the 
important aspects of both modifications should be possible. 

This thesis is directed towards developing a precisely 
defined model which shows how this can be accomplished for 
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Figure 4. The Notion of Change Propagation Represented 
Graphically. 


PSDL programs. In Chapter II, we review some work previously 
done on merging pure extensions and integrating modifications. 
In Chapter III, we take the ideas described in Chapter II and 
adapt them to PSDL to formulate our model. 
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Figure 5 . The Idea of Merging Two Different. Versions of a Base 
Program into a Merged Program with the Significant 
Capabilities of Both Versions is Similar to Propagating 
Changes. 
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II. PREVIOUS WORK 


This chapter explores some of the work that has been done 
by other researchers in this area. Section A discusses work 
on merging software extensions. [Ref. 10] Section B presents 
an approach to integrating non-interfering software 
modifications. [Ref. 11] 

A. MERGING SOFTWARE EXTENSIONS 

1. Extension vs. Modification 

Program extensions are additions to the program 
which extend the domain of the partial function without 
altering initially defined values. Modifications are 
additions or changes which do alter initially defined values. 
In other words, program extensions add functionality to the 
base program without altering the already existing 
functionality. For example, consider the program in Figure 6. 
This program takes two real numbers as input, checks to see if 
the first is an approximation of the second, and prints "True" 
if the difference is relatively small and "False" otherwise. 
This program can fail to produce an output for some inputs, 
namely y = 0.0. It can easily be extended by adding a filter 
to check for this possibility, as shown in Figure 7. 

Program modifications, on the other hand, change the 
original functionality of the program. Program Approx 2, 
shown in Figure 8 is an example of a modification. This 
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program Approx(input, output); 
const 

eps := 0.00001; 

var 

x, y: real; 

begin 

readln(x); 
readln(y); 

if (abs((x - y)/y) < eps)) then 
writeln ("True"); 

else 

writeln("False"); 

end. 


Figure €. Example: Program Approx Diverges if y = 0. 


program Approx_l(input, output); 
const 

eps := 0.00001; 

var 

x, y: real; 

begin 

readln(x); 
readln (y); 
if (y <> 0) then 

if (abs((x - y)/y) < eps)) then 
writeln("True") 

else 

writeln ("False") 

else 

if (abs (x - y) < 0) then 
writeln ("True") 

else 

writeln("False") 

end. 


Figure 7. Example: Program Approx_l is a Compatible Extension 
of Approx Which is Defined for all Inputs. 








program computes a slightly different approximation relation 
than the program Approx. Since the program no longer provides 
the original functionality, a modification has occurred. 

More formally, using an approximation ordering C, 
if p is a base program and p C q, then p approximates q and 
q is an extension of p. That is to say that q agrees with p 
everywhere p is defined, and q may be defined in cases wb ?re 
p is not. [Ref. 10] 


program Approx_2(input, output); 
const 

eps := 0.00001; 

var 

x, y: real; 

begin 

readln (x); 
readln(y); 

if (abs((x - y)) S eps)) then 
writeln("True"); 

else 

writeln ("False"); 

end. 


Figure 8. Example: Program Approx_2 Uses a Different 
Approximation Method. 


With this ordering in mind, two specifications p and 
q can be merged by finding the least common extension of 
p and q, written p U q, where p and q are base specifications 
and p U q is the merged specification. The least common 
extension is in general not computable, so an approximation is 
used. [Ref. 10] 
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2 . 


Definitions 


In [Ref- 10]/ only four domains were considered; 
specifications, functions, programs, and data types. These 
four domains are defined in Figure 9. All domains are treated 
as lattices. 1 The lattice for a domain representing a data 
type D 0 can be defined as the set D = D 0 { _L, T }, where 1 
approximates everything and T is an extension of everything. 
The definition of the extension relation for D is: 

x C y ( _L = x ) v ( x = y ) v (y = T ) 2 


Specification: 
Function: 
Program: 

Data Type: 


Models Intended Behavior 

Implements Actual Behavior 

Algorithms Defining Partial 
Functions 

Set on which Programs Operate 


Figure 9. Definitions of Relevant Domains. 


lattices are partially ordered sets with a least upper 
bound and a greatest lower bound. [Ref. 10] 

2 The strong equality relation x = y results in True if x 
and y are the same element, and False otherwise, for all 
elements of D including _L and T . 
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In merging extensions, X represents an unsuccessful 
computation, and T represents the results of combining 
incompatible 3 data values. 

In [Ref. 10] data types are viewed as heterogeneous 
algebras, where each primitive operation f of the algebra is 
extended to a full lattice via the following properties: 

1. x t = X => f(x lf ..., x±, . . ., x n ) = X and 

2. (Xi = T & x 3 % 1 for_1 < j < n) 

f (x,, . . ., x lf ..., xj = T, for 1 < i < n. 

Property 1 says that for any element x t , if x A = 1 
then any operation f with x A as a parameter returns X. 
Property 2 says for any x A in the parameter list of f, if x A 
= F and no x 3 s X then f returns T . Conditionals for this 
domain are extended by the following: 

1. (if X then x else y) == X 

2. (if T then x else y) = T. 

The domains for functions and specifications are 
defined as mappings on data type domains, as shown in Figure 
10. Orderings for these domains are defined as follows: 

1. For f,g €: Func, f Q g Vx G D[f(x) C g(x) ] . 

2. For s, t G Spec, s L t < J = ^ Vx G D, 

y G R[s(x,y) L t(x,y)] . 


3 An unsuccessful computation includes infinite 
computations, and computations which terminate abnormally or 
with an error message. 
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Func = D —> R 

Spec = [D x R] —» Bool 

D, R are Data Type Domains. 

D —> R is a set of continuous functions 
with respect to C . 

Figure 10. Domains for Functions and Specifications. 

The limitation to continuous functions is not 
considered a "serious restriction", as all computable 
functions are continuous. 4 [Ref. 10] 


Dom: Spec Poverset [ D ], 

Dom(s) = {x e Dl 3 y e R [True C s(x,y)]} 
Sat: [Func x Spec] —* Bool, 

Sat(f, s) c=> V x € Dom(s) [True C s(x,Jf(x))] 


Figure 11. Definitions of Domain and Satisfy. 

Since specifications which leave part of the input 
space unconstrained are of interest, the definitions shown in 
Figure 11 are provided to clarify what it means for an input 
value to be in the domain of a specification and for a 
function to satisfy a specification. The domain of a 

4 A function f is continuous if and only if f (Us) = Uf (S) , 
for all directed sets S. S is directed if and only if every 
finite subset of S has an upper bound in S. 
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specification is that set of input values for which an 
acceptable response can be provided, thus Dom(s) is the set of 
values of x in the input domain D for which there exists an 
output value y in the output domain R . A specification for 
a function f applied to a pair (x, y) will yield a True if y 
is an acceptable value for f (x) , False if not, X if the 
specification does not say whether y is acceptable, or T if 
the specification is inconsistent with respect to whether y is 
acceptable or not. T would be the result if two conflicting 
specifications were merged. A function f satisfies a 
specification s if and only if for every value x in the domain 
of s, f returns a value which is acceptable. Figure 12 shows 
an example used in [Ref. 10] to clarify this idea. The 
specification s yields X if x < 0. In these cases, a correct 
function can yield any value. 

s(x,y) = if 0 < x then I (y - x 2 ) I < £ else X. 

Figure 12. Example: A Specification for a Square Root 

Function. 

3. Program Merging 

The least common extension of two functions is not 
computable m general. [Ref. 10] Since the least common 
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extension is the desired result of a merge operation, the 
theorem shown in Figure 13 is provided. 5 


Theorem : Correctness of Extensions 

If s, t are monotonic, f c h, g C h, 

Sat (f, s ), and Sat(g, t) then Sat(h, (s U t)). 


Figure 13. Correctness Theorem. [Ref. 10] 

This theorem states that given two monotonic 6 
specifications, s and t, and three functions, f, g and h, if 
f satisfies s and g satisfies t, then any common extension h 
of f and g satisfies the least common extension of s and t. 
The function h is an approximation for the least common 
extension of f and g, and is sufficient. An approximation can 
yield an inconsistency in some cases where consistent 
combinations are possible, but an inconsistency is more 
acceptable than an undefined or diverging computation, because 
it can be detected at merge time. 

A program consists of a set of function definitions 
accompanied by an expression. The merging of two such 


S A proof of the Correctness Theorem can be found 
in [Ref. 10]. 

6 A function f is monotonic if and only if 

x C y =s> f (x) C f (y) . 
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programs will result in a third program containing a set of 
functions according to the following rules: 


1. Functions which appear in one of the input programs 
and not in the other will appear in the merged 
program unchanged. 

2. Functions which appear in both of the input 
programs with the same number of parameters, will be 
merged. 

3. Functions which appear in both of the input programs, 
but with a different number of parameters, will be 
merged. The formal parameter list will contain a T at 
the place where the inconsistency occurs. 

Expressions are merged using normal forms. [Ref. 10] 
uses rewrite rules to reduce expressions to normal forms. For 
example, consider the rewrite rules: 

1 . y + w x 

2. z w 

Using these rewrite rules on the expression 
(x x (y + z)) reduces it to the expression (x x x). Figure 14 
provides an example of their use. Normal form merging can be 
strengthened if axioms and theorems about the data structures 
are added to the rewrite rules. 

Function definitions can be merged using normal 
forms also. Semantically equivalent function calls are merged 
by renaming formal parameters in one input version to match 
the other version, if necessary, and inserting it into the 
merged program. Even some function calls with the same number 
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(if x = y+ w&w=z then x x (y + z) else 1) 


merged with 

(if x = y + w & w = z then x x (y + w) else 0) 
yields 

(if x=y+w&w=z then x x x else 0) 

Figure 14. Example: A Merge Using Rewrite Rules. 


of arguments, but not semantically equivalent can be 
consistently merged by creating a new function. 

The work done in [Ref. 10] was the first of its kind 
that we were able to find. It provides a mathematical 
foundation for performing program merges, and shows that 
merging programs is possible. The next section builds upon 
this foundation, and provides an algorithm for merging two 
modifications of a base program. 

B. AN ALGORITHM FOR INTEGRATING PROGRAM MODIFICATIONS 

Many times in the software evolution cycle, base programs 
are altered or enhanced in different ways to meet the needs of 
different customers. This leads to the development of 
parallel genealogies, as described in Chapter I. At a later 
time in the evolution cycle, a customer may want a program 
which has all the capabilities of two different genealogies. 
This leads to the need for some automated way of integrating 
two genealogies into a single working program. This automated 
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integration method could also be used to propagate changes 
made to a base program through all of its offspring. This is 
accomplished by making the change to the base program, and 
then integrating that changed base program with each of the 
offspring. 

In [Ref. 11], an algorithm is presented for integrating 
two non-interfering modifications of a base program. The 
integration produces a third program which reflects both 
modifications. This integration method can be useful in 
recombining parallel genealogies as illustrated above. The 
algorithm uses program dependence graphs (PDGs) to abstractly 
represent the programs, then by using program slicing, 
determines which portions of the two versions are different 
from the base program. Using this information, the algorithm 
determines if the changes interfere 7 with each other. If they 
do not interfere, the different program slices are combined 
into one integrated PDG, which is then transformed into the 
final version of the program. 

1. Program Dependence Graphs 

As mentioned earlier, [Ref. 11] uses PDGs to 
automate the merging process. A PDG for a program P is a 
directed graph, G p with several kinds of vertices connected by 


’Versions A and B interfere with respect to a Base 
program if 3 an initial state and variable x such that A, B, 
and Base all compute different values of x. 
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several different kinds of edges. The vertices represent one 
of the following: 


1. The Entry Vertex 

2. Initial Definitions: "x := Initial_State(x)" 

3. Assignments 

4. Control Predicates 

5. Final Use Statements: "Final_Use(x)" 

Edges represent dependencies between vertices: 

1. Control Dependencies: => c 

2 . Data Dependencies: 

a. Flow Dependence: => f 

b. Def-Order Dependence: => do 

Control dependence edges, v 2 => c v 2 are contained in 
G p if and only if one of the following properties holds: 


1. V; is an entry vertex and v 2 represents a component of 
P not subordinate to a control predicate. This type of 
control dependence edge is always labeled True. 

2. v x is a control predicate and v 2 is a component 
immediately subordinate to v 2 . 

a. If v 1 is a while predicate and v 2 is in the loop 
body, the edge is labeled True. 

b. If v t is a conditional predicate, the edge is 
labeled True if v 2 is on the then branch. False if 
v 2 is on the else branch. 


Data dependence edges, v 2 => v 2 indicate that v x must 
occur before v 2 for data to be valid. G p contains a flow 

dependence edge, v 2 v 2 if and only if: 
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1. v x defines a variable, say x. 

2. v 2 uses x. 

3. Control can reach v 2 after v 2 along a path that 
doesn't change the value of x. 

Flow dependence edges due to a particular x appear 
as {=>/) . Flow dependencies are further classified as loop 
carried (=5> lc )or loc ) independent (=S> 2i ) . v 2 is dependent on v 2 
along a loop independent edge, v x v 2 , if in addition to a, 

b and c above, there is an execution path that satisfies c and 
does not include a backedge to the predicate of the loop that 
encloses v 2 and v x . v 2 is dependent on v 1 along a loop carried 
edge for a loop L, v x => ic(L) v 2 , if in addition to 1, 2, and 3 
above, the following properties also hold: 

4. There is an execution path which satisfies 3 and 
includes a backedge to the predicate L. 

5. v x and v 2 are enclosed in loop L. 

Def-order edges, v x => da v 2 , appear in G if and only 
if the following properties hold: 

1. v x and v 2 are both assignments to the same variable x. 

2. Vj and v 2 are in the same branch of every conditional 
statement that encloses them. 

3. There is another vertex v 3 that reads x and is 
dependent on both v x and v 2 along flow dependence edges. 

4. v x occurs before v 2 . 

Using these components, a program dependence graph 
can be constructed for any program. Figure 15 she s an 
example of a simple program and Figure 16 shows its 




program nada 

sum := 0; 
x := 1; 

while x < 11 do 

sum := sum + x; 
x : = x + 1 ; 

end 

end(x, sum) 


Figure 15. Example: A Simple Program to Illustrate Program 
Dependence Graphs. 



Figure 16. Example: The Program Dependence Graph for the 

Program nada. 


associated PDG. By analyzing parts of this graph which affect 
a certain variable, one is able to observe the effects of a 
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change to the program with respect to that variable. This is 
done using a technique known as program slicing. 

2. Program Slicing 

The program slice of a graph G with respect to a 
vertex s is the subgraph of G containing all vertices which 
can reach s by way of control or flow dependence edges, along 
with the edges. 

V(G/ s) = {w e V(G) | w => c * s} 

To get the slice of a graph G with respect to one of 
the output variables, say x, merely take the slice with 
respect to the vertex labeled "Final_Use(x)". Def-order edges 
are contained in the slice only if the vertex which depends on 
it is also included in the slice. This can be extended to a 
set of vertices S = {s lf s 2 , ..., s*} by taking the union of 
the vertex sets of all of the individual program slices. 
Figure 17 shows an example of slice of the program nada taken 
with respect to the variable x. Figure 18 shows the 
corresponding PDG. 

3. Program Semantics and Program Dependence Graphs 

The problem with text merging, as has been pointed 

out several times, [Ref. 10,11] is that it discounts the 
influence of semantics on program structure. In merging 
programs, the semantics must be merged as well. PDGs provide 
a way to do that. 
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program nada_x 
x : = 1 ; 

while x < 11 do 
x : = x + 1 

end 
end(x) 


Figure 17. Example: The Slice of the Program nada Taken with 
Respect to x. 



Figure 18. Example: Program Dependence Graph for nada_x. 

It can be said that two programs are equivalent if 
they provide the same results for all possible input values. 
Two programs P & Q are strongly equivalent, if and only if, 
for all possible states <7, P & Q both diverge when initiated 
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at o, or they both halt with the same final values. If they 
are not strongly equivalent, then they are not equivalent. 


[Ref. 11] provides the theorem shown in Figure 19. This 
theorem states that if two PDGs are isomorphic then their 
representative programs are semantically equivalent. The 
contrapositive to that is inequivalent programs have non¬ 
isomorphic PDGs. 

Theorem: If P, Q are programs such that G p is isomorphic 
to G 0 , then P is strongly equivalent to Q. 


Figure 19. Strong Equivalence Theorem. 


Another theorem stated in [Ref. 11] is the Slicing 
Theorem shown in Figure 20. This theorem states that for Q, 
a slice of program P, P & Q behave equivalently at all places 
which are common to both P & Q. 


Theorem : Let Q be a slice of program P with respect to a 

set of vertices. If a is a state on which P halts, then 
for any state o' that agrees with a on all variables for 
which there are initial-definition vertices in G 0 : 

(1) Q halts on O '. 

(2) P and Q compute the same sequence of 
values at each program point of Q. 

(3) The final states agree on all variables 
for which there are final-use vertices in G 2 . 


Figure 20. Slicing Theorem. 
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4. Determining Behavior Difference* in Variants 

In order to integrate two different versions of a 
base program, their differences from the base must be 
determined. This can be done using the PDGs of the different 
versions. This model assumes that only changes in the 
behavior of a modification with respect to its base are 
significant. If the slice of G BASE with respect to a vertex v 
is different from the slice of GA, where A is the 
modification, with respect to v, then this is an indication of 
possible changed behavior. All such vertices where G BASE and 
G A differ are called the affected points AP a base of G A . The 
slice G a /AP a base is a graph which captures the behavior of A 
that is different from the BASE. Determining the affected 
points by checking the program slices for every vertex in the 
graph is not very efficient. [Ref. 11] presents a function 
for doing this that requires at most two complete examinations 
of the graph. It is the function called AffectedPoints [Ref. 
11, P. 21], and is based on the following three observations: 

1. All vertices in G A but not in G BASE are affected points. 

2. Each vertex w of G A with a different set of incoming 
flow or control edges than in G BASE gives rise to a set of 
affected points, namely the vertices which can be reached 
via zero or more flow or control edges from w. 

3. Each vertex w of G A with an incoming def-order edge, 
due to a vertex u that does not appear in G BASE , gives rise 
to a set of affected points, namely the vertices that can be 
reached via zero or more flow or control edges from u. 
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5. Merging Program Dependence Graphs 

Once the PDGs have been created for the different 
modifications and the base, and all the differences between 
the modifications and the base have been determined, the 
merged PDG G M must be created. G M is formed by taking the 
union of the slices representing the changed behaviors of 
versions A and B with respect to the base and the s ice 
representing the preserved behavior of the base in both 
versions A and B. This final slice contains the subset of 
V(G 8ASE ) for which the slices in all three versions are 
isomorphic, and is represented by PP B ase,a,b- 

1. PPbase.a.b = € V(G base ) | <G BASE /v) = (G a / v) = (G B /v) } 

2* G m — (G a /AP a BASE ) (G B /AP B BASE ) (G base /PP base a b ) 

6. Determining Interference Between Modifications 

A merged PDG created as described above can 
inaccurately reflect the changed behavior of the two 
modifications in two ways. First, the union of two feasible 9 
PDGs is not necessarily a feasible PDG. Secondly, G m may not 
preserve the differences in the behavior of the modifications 
with respect to the base. Interference when either of these 
conditions occurs. Testing for interference due to the first 
condition is done during the program reconstitution process. 
A theorem is provided in Reference 5 which states that the 

®A PDG G P is feasible if it is a PDG for a program P. The 
slice G/S is feasible if S c V(G) and G is feasible. 
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function ReconstituteProgram will succeed if and only if G>, is 
feasible. Testing for interference due to th<=> second 
condition can be done by merely checking the following 
condition: 

G M /AP X 8ASe = G a /AP abase and G m /AP bbase = G b /AP bbase 

7. Program Reconstitution 

Program reconstitution is accomplished through the 
use of a function called ReconstituteProgram. This function 
first attempts to order the tree created by the control 
dependencies between the vertices using the flow dependencies. 
It then transforms the graph into an abstract syntax tree from 
which a program is formed. A PDG is then created for the 
program created and is checked against G„. This function will 
fail if either the vertices cannot be ordered or the PDG of 
the created program is not isomorphic to G M . 

The algorithm Integrate described in this section is 
far from perfect, but up to this time, seems to be the most 
complete work of its kind. Portions of the algorithm still 
have problems, though. One example is that the ordering of 
the vertices done in Step 5 of the algorithm is a problem that 
is NP-Complete. 

C. SUMMARY 

In this chapter, we have explored two different 
approaches to the software integration px'oblem. In Section A, 
work done in modelling the merging of pure extensions of a 
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program was presented. This provided a sound foundation for 
understanding the work done in Section B. Section B explored 
the integration of non-interfering versions of programs 
through the use of program dependence graphs and an algorithm 
for integrating different slices of the graphs for different 
versions into a merged graph, from which a merged program can 
be created. These two bodies of work have helped 
significantly with our understanding of the complexities of 
program integration and the development of a model to account 
for those complexities. 
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III. A MODEL FOR MERGING PSDL PROGRAMS 


PSDL programs are made from the combination of one or 
more Abstract Data Types and/or Operators. Since, for the 
current implementation of PSDL, all Abstract Data Types are 
implemented in Ada, merging them is not within the scope of 
this thesis and is not included in our model. We do model the 
merging of a base PSDL operator, Base, with two modifications 
or extensions, A and B, of Base, into a least common 
extension, M. We refer to this three-way merging model as 
"change-merging", to prevent confusion with other merging 
models. This chapter defines the operations, 11, U, and -, 

and the relation C as they pertain to change-merging A, Base 
and B into M. As was pointed out in Chapter 2, [Ref. 10] 
tells us that the least common extension of two programs is 
not computable in the general case. This fact is also true 
with PSDL programs. We will show that an approximation to the 
least common extension is enough to provide a successful 
change-merge in most cases. 

The relation C is defined as the approximation relation 
for the lattice created by combining all PSDL operators 
together with a T and a 1 as shown in Figure 21. If Y is an 
extension of X, then we say X approximates Y, written X C Y. 
The F, or top element, is an extension of all possible PSDL 







operators. This is an overconstrained artificial component 
which represents an inconsistency. The -L, or bottom element, 
is an approximation of all possible PSDL operators. This is 
an artificial unconstrained component that represents an 
undefined element. Having these components in the lattice 
provides a way for us to completely define a change-merge 
operation on PSDL operators. If T is the result of a change- 

merge operation, there is no consistent way to provide a 
change-merge that is syntactically correct. _L, on the other 
hand, is a component that is an undefined (i.e. an 
unimplemented or non-terminating program). 

The difference between two PSDL operators, A - B, gives 
the behavior found in A and not in B. Any functionality which 
is common to both operators is not included in A - B. The 
greatest common approximation of two PSDL operators, A and B, 
is written A LI B. The greatest common approximation of three 
operators, A H Base FI B gives us the behavior which is common 
to all three operators. 

To get the desired behavior of M we must combine this 
common behavior, A (1 Base L! B, with the difference between 

the behavior of Base and each of the two modifications or 
extensions, A - Base and B - Base. From this we can conclude 
that change-merging the three versions can be done using the 
following formula: 

M = A[Base]B = (A fi Base LI B) Li A - Base U B - Base. 
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Figure 21. 


The Set of All PSDL Operators Forms a Lattice. 


It turns out that it is not necessary to use the greatest 
common approximation of all three operators. The difference 
between A H B and A ("1 Base fl B is contained in the 

modifications A - Base and B - Base, as shown by the following 
equations and inequalities: 

(A H B) ~ (A fl Base f! B) = (A 11 B) - Base = 

(A - Base) fl (B - Base) C 
(A - Base) U (B - Base) 

Thus in merging the three versions, it is sufficient to 
merge the greatest common approximation of A and B with the 
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behavior differences between the two modifications and the 


Base, as shown in the following: 

M = A [Base] B = (A f! B) Li (A - Base) U (B - Base) . 

This chapter defines what this equation means in change¬ 
merging the different components of a PSDL operator. 

PSDL operators consist of two major parts: a 
specification and an implementation. 1 The specification of 
an operator A, denoted S A 2 , defines the external interfaces of 
the operator and identifies its functionality through the use 
of text descriptions and keywords. The change-merging of two 
PSDL specifications is discussed in Section A. The 

implementation part of an operator A provides an Enhanced Data 
Flow Diagram consisting of a data flow diagram, a set of 
internal data streams, and a set of constraints which control 
the internal operations of the operator. For this model, we 
separate the implementation part of the operator into two 
separate and distinct problems. The first is change-merging 
two simple data flow diagrams, denoted D A and D„, discussed in 
Section B, and the second is the integration of two sets of 
internal data streams, denoted DS A and DS„, and control 
constraints, denoted C A and C B , discussed in Section C. 


x The change-merging of specifications and implementations 
is different, so we handle it separately. 

2 In our model, the subscript of a set signifies which 
operator it represents. 
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A. SPECIFICATIONS 

The specification of a PSDL operator, A, tells the rest 
of the program what the operator does. Changes to the 
specification of an operator ptoentially affect all of the 
other parts of the program where the operator is used. We 
assume the author of a change to an operator specification has 
also made the necessary changes in all of the contexts where 
the operator is used. For this reason, change-merging 
operations must be applied to entire prototypes. However, 
changes to entire programs are merged by merging changes to 
corresponding sub-components. This section focuses on the 
change-merge operation for the specification of each sub¬ 
component . 

1. Interfaces 

The interface of a PSDL operator is the definition 
of the operator's external contacts. It contains the input 
set expected by the program, I A , the output set that can be 
expected, 0 A , and the set of generic parameters that may be 
instantiated, GN A . I A , 0 A , and GN A are all ordered sets. It 
also contains a set of internal state variables, St A , a set of 
possible exceptions, E A , and a set of timing requirements that 
are met by the program, T A . St A , E A , and T A are all unordered 
sets. 

a. Ordered Seta 

Ordered sets are a significant building block 
for many programming languages, including PSDL. For the 
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purpose of change-merge operations, ordered sets should be 
modelled using a flat lattice, as shown in Figure 22. When 
the order of a set is significant, then any change made to the 
set is an incompatible change and creates a set which is 
neither an approximation nor an extension of the original set. 
This means that the only set which is an approximation for the 
order* i set is the undefined set, signified by the J_ in Figure 
22, and the only set which is a compatible extension of the 
ordered set is the overconstrained set signified by the T in 

Figure 22. The applications of this structure to PSDL 
specifications are explained next. 



Figure 22. Ordered Seta Have a Flat Lattice Structure. 





(1) Input and Output 3 

Input and Output interfaces are sets of 
input and output streams. The order of these sets is 
significant because actual parameters are associated with 
formal parameters based on the order in which they appear. In 
change-merging I x , I 8 and 1*.,, into I M , any change between the 
interface set of Base and the two modified versions is 
significant, and must be preserved in the change-merged 
version. The change-merged set of inputs, or outputs, is 
determined by the following rule: 

i M = * a* -1...j u (i fc n i B ) li <i B - i b „j 

Based on this rule, one of the following 
three situations can occur: 

1. If both of the modifications have the same interface 

set as the base, then: I M = JL U I Ba „ U 1 - I B .„. 

2. If one of the two modifications, say I x is the same 
as the base, and the other is not, then: 

i H = i U i Ll i B = i B . 

3. If both of the modifications are different from the 

base version, then: I H = I, 1) i U I B = T . 

The first situation is the case in which 
no changes were made between the inputs of the Base and the 
two modifications. In this case, the change-merged version 


3 The change-merging of input and output sets is 
identical, so only the change-merging of input sets is shown 
here. 
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should have all of the same inputs, or outputs. The second 
situation is the case in which only one of the modifications 
changed from the base. In this case, the change from the base 
is significant and must be preserved in the change-merged 
version. The third situation is the case where both of the 
modifications changed from the base. The result is a conflict 
because there is no proper PSDL specification that is 
consistent with both modifications. 

An example of an interface change-merge is 

shown in Figure 23. In this example, I* t- I B .„, but I B = I B «..> 
SO I M = I A . C>b<j«« ^ 0 A ^ Ob / so 0 M = T . 


S B „. = INPUT 

x: integer 
y: real 
OUTPUT 

w: integer 
z: string 

S B = INPUT 

x: integer 
y: real 
OUTPUT 

w: integer 


S A = INPUT 

x: integer 
OUTPUT 

w: integer 
t: integer 
z: string 


Sh = 


INPUT 

x: integer 
OUTPUT 

T 


Figure 23. Example: An Interface Merge. 
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(2) Generic Parameters 


The Generic interface is contained only in 
template operators. Template operators are operators in the 
Software Base used to instantiate software components. 
Change-merging generic parameters is similar to change-merging 
input and output parameters with the exception that in 
addition to value parameters, generic parameter sets may also 
contain operator parameters and type parameters. Changes to 
generic sets will follow the same rules as Input and Output 
sets. Figure 24 shows an example of a change-merge operation 
on generic parameters. 

b. Unordmrmd Sets 

Unordered sets are modelled using a "Powerset 
Lattice" 4 , as shown in Figure 25. Because unordered sets are 
modelled using this type of lattice, more freedom can be 
exercised in change-merging them. Change-merge operations do 
not follow the same rules for these unordered sets as for 
ordered sets. 

(1) States 

State variables differ from input and 
output variables in that, abstractly, they are tuples, 
containing a name, a type and an initial value. As the set of 
state variables is unordered and invisible to the rest of the 
program, the state set can be increased or decreased without 

4 A "Powerset Lattice" is a lattice whose ordering is 
based the powersets of a given data type. A is a compatible 
extension of B, if A is a subset of B. 








GN,„. = GENERIC 

tl: type, 
t2: type, 

ol: operation[il,i2:tl,ol:t2], 
vl: integer 

GN k = GENERIC 

tl: type, 
t3: type, 

o2: operation[il:tl,ol:t3], 
vl: integer 

GN b = GENERIC 

tl: type, 
t2: type, 

ol: operation[il,i2:tl,ol:t2], 
vl: integer 

GN m = GENERIC 

tl: type 

t3: type 

t4: type 

o2[il:tl,ol:t3], 

vl: integer 


Figure 24. Example: A Merge of Generic Parameters. 


affecting other parts of the program. In change-merging state 
variable sets, the operations [1, U, and - are equivalent to 
the corresponding set operations, kJ, O and The third part 
of the tuple, the initial value, requires an additional check 
in the change-merging process. These initial values are 
ordered using a flat lattice, because they are ordinary data 
values. The initial value of a change-merged state variable 
follows the same change-merging rules as input and output 
variables. If all three versions have different initial 
values for the same state variable, then the change-merged 
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{a, b, cj 



{} 

Figure 25. Unordered Sets Have a Powerset Lattice Structure. 


version will contain a T in the place where the initial value 
is assigned. If only one of the modifications assigns a 
different initial value than the base version, then the 
change-merged version will contain the initial value of the 
one that was different. Figure 26 shows an example of change¬ 
merging state variable interfaces. In this example, the state 
variable s is assigned a value in Base which is changed by 
version A, but not B. 

(2) Exceptions 

The exceptions interface is a list of 
identifiers which denote exception values which may be 
returned by the operator. Consequently LI, fl, and - can be 
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STATES 

s: integer initially 0 
t: real initially 30.0 


St A = 

STATES 

r: natural initially 10 
s: integer initially 5 
t: real initially 10.0 


St, = 

STATES 

p: integer initially 0 
s: integer initially 0 
t: real initially 20.0 


0 

10 


St M = 

STATES 

p: integer initially 
r: natural initially 
s: integer initially 5 
t: real initially T 


Figure 26. Example: A Merge of State Variable Interfaces. 


interpreted as the corresponding set operations, tJ, O, 
Exceptions which appear in one or both of the modified 
versions, and not in the base, will appear in the change- 
merged program. Exceptions which appear in the base and do 
not appear in at least one of the modifications will not 
appear in the change-merged program. The following formula 
defines the exception set of the change-merged program, E M : 

E m = [E, n E t ] U [E a - E B „J U [E b - E b ...] 

The expression E A E„ yields the set of 
exceptions which are common to all three versions. The 
expression E A - E Bm . yields the set of exceptions which are in 
modification A and not in the base. The expression E B - E B .,„ 
yields the set of exceptions which are in modification B and 
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not in the base. These sets are added together to form E M . 
An example of a change-merge on exception sets is found in 
Figure 27. 


E b „. = EXCEPTIONS 

EXCEPTIONI, 
EXCEPTI0N2, 
EXCEPTI0N3 


E a = EXCEPTIONS 

EXCEPTI0N1, 
EXCEPTI0N2, 
EXCEPTIONS 


E b = EXCEPTIONS 

EXCEPTI0N1, 
EXCEPTION3, 
EXCEPTION4 


E M = EXCEPTIONS 

EXCEPTIONS 
EXCEPTION4, 
EXCEPTIONS 


Figure 27. Example: Merging Exception Sets. 


(3) Timing Information 

There are three different types of timing 
information found in specifications of PSDL operators, Maximum 
Execution Time(MET), Maximum Response Time(MRT), and Minimum 
Calling Period (MCP) . MET is the maximum CPU time that an 
operator can use to perform its assigned task. MRT is the 
maximum amount of real time between the arrival of an input 
value on the input stream and the placement of an output value 
on the output stream. MCP is the minimum amount of time 
between invocations of an operator. 
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Change-merging MET, MRT and MCP timing 
information is done in much the same way as state variable 
definitions. If the timing information is unchanged in both 
modifications from the base, then it will remain the same in 
the change-merged version. If it is the same in one of the 
modifications as the base, but different in the other, then 
the changed value will be the value assigned to the change- 
merged version. If all three versions contain a different 
timing value, then the change-merged version will contain a 
timing value of T. Examples are shown in Figure 28. 


MET 20 [ MET 20 ] MET 20 = MET 20 
MCP 40 [ MCP 40 ] MCP 30 = MCP 30 
MRT 10 [ MRT 20 ] MRT 30 = MRT T 

Figure 28. Examples: Merging Timing Information. 

2. Functionality 

The functionality of an operator specification is 
what differentiates it from other operators. Through the use 
of keywords, the operator can be distinguished from other 
operators in the database during the retrieval process. Text 
descriptions are provided for use by the engineer. Axiomatic 
descriptions are provided to allow expert system techniques to 
be used in the retrieval process. 
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a. Keywords 

The keywords section of an operator 
specification is a set of distinguishable words which 
explicitly identifies the functionality of the operator. The 
order of these words is not significant. The change-merging 
of the set of keywords is done in the same way as the set of 
exceptions. 

Jb. Informal Description 

The informal description of a PSDL operator is 
a textual explanation of the functionality of the operator. 
It has no formalized sub-structure, therefore, the accurate 
change-merging of textual explanations, is not within the 
scope of this thesis. It is assumed that accurate change¬ 
merging of the informal description will be done by the 
engineer overlooking the change-merge operation, 
c. Formal Description 

The formal description of the PSDL operator 
provides an axiomatic representation of the functionality of 
the operator. Mathematical properties can potentially be 
automatically change-merged using currently available 
technology, but as this portion of the language has not yet 
been determined in detail, it is impossible for us to provide 
a method at this time. 

B. DATA FLOW DIAGRAMS 

A PSDL Data Flow Diagram, for an operator A, is a graph 
D a = {O, L}, where O is a set of vertices which represent the 
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component operators of A, including the constant operator EXT 
representing external contacts, and where L is a set of 
links(labelled edges) which represent the data streams 
entering and leaving the elements of 0. The labels for the 
links are the names of the data streams they represent. 

Between any two vertices, o 2 and o 2 , there is an edge for 
each data st earn, x, that is an output of o : and an input for 
o 2 . A data flow diagram can have parallel edges, since 
operators can have multiple outputs and/or multiple inputs. 
Figure 29 shows three examples of PSDL Data Flow Diagrams: 

1. An operator with no inputs or outputs. 

2. An operator with one input and one output. 

3. A composite operator with multiple data streams between 

its two component operators and multiple output streams. 

We define the change-merging operations on PSDL data flow 
diagrams in terms of a bipartite graph B x = (V, S, LI, LO} , 
where V is the set of operators in D*, S is a set of vertices 
which represent the data streams of operator A, LI is a set of 
edges from a stream vertex to an operator vertex, representing 
input links, and LO is a set of edges from an operator vertex 
to a stream vertex, representing output links. According to 
this model, the data flow diagrams in Figure 2 9 have the 
following bipartite graph representations: 
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Figure 29. Example: £>SDL Operator Data Flow Diagrams 


1. G.V = {A,EXT} 

G.S = {} 

G.LI = {} 

G.LO = {} 

2. G.V = {B,EXT} 

G.S = {a,b} 

G.LI = {(a,B),(b,EXT)} 

G.LO * { (EXT,a) , (B,b) } 

3. G.V = (C,D,EXT} 

G.S = {x,j,k,y,z} 

G.LI = { (x,C) , (j,D) , (k,D) , (y,EXT) , (z,EXT) } 
G.LO = { (EXT, x) , (C, j) , (C,k) , (D,y) , (D, z) } 


Figure 30 gives graphical illustrations of these 
bipartite graphs. 

The bipartite graph models have no edges which link an 
operator vertex with another operator vertex, or a stream 
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vertex with another stream vertex. For each input to an 
operator vertex, v x , there is an edge in LI which flows from 
a stream vertex s x . For each output from an operator vertex 
v,, there is an edge in LO which flows to a stream s 2 . 

Change-merging the data flow diagrams is done by change¬ 
merging the graphs G,.,., G x and G, by subsets V, S, LI and LO. 
The operations U, 11, and - can be interpreted as the 
corresponding operations 'U , O, and -. The following equation 
defines the way this change-merge is accomplished: 

G* = [G* - G b ..J Lj [G a n G b ] u [G, - g b ..j 
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The greatest common approximation is obtained for the 
Base and the two modifications by taking the intersection on 
all components of the graph. Then these common components are 
added to the disjoint components of each modification by 
subtracting out the parts of the two modifications which are 
also in the base. This operation preserves the functionality 
common to all the versions, while ensuring that significant 
changes made by the two modifications are included in the 
change-merged graph. An example of change-merging operations 
on bipartite graphs is shown in Figure 31, and illustrated 
graphically in Figure 32. 


Base.V = {A,EXT} 

Base.S = {x,y} 

Base.LI = { (x, A),(y, EXT)} 
Base.LO = {(EXT,x),(A,y)} 


A .V = (A,A1,EXT} 

A.S = {x, y } 

A.LI = {(x,A),(x,Al), 
(x,y,EXT)} 

A.LO = {(EXT,x),(A,y) 
(Al, y) } 


B.V = {A,B,EXT} 

B. 3 = {x,y,t} 

B.LI = {(x,A),(y,B), 

(t, EXT) } 

B.LO = {(EXT,x),(A,y), 
(B, t) } 


M.V = {A,Al,B,EXT} 

M.S = {x,y,t} 

H.LI = { (x ,A), (x,Al), (y,B) , (t ,EXT) } 
M.LO = { (EXT,x), (A,y) , (Al,y) , (B,t) } 


Figure 31. Example: Merge Operation on Data Flow Diagrams. 

In this example, the change-merged set of operator 
vertices is obtained by adding together the operator vertices 
which are common to all three versions with the operator 
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Figure 32. Graphical Illustrations for the Merging Operation 


in Figure 31. 


vertices which are particular to the modifications. The sets 
of stream vertices and the sets o" edges are treated 
similarly. 


58 









C. DATA STREAMS AND CONTROL CONSTRAINTS 
1. Data Streams 

A set of data stream definitions, DS A defines 
variables which exist internally to the operator, A, and are 
not defined in the specification. The order in which the 
declarations appear is not significant. They have the same 
structure as exception declarations, and can be change-merged 
using the same rules. If a stream appears in DS Ba> ., then it 
appears in DS M if and only if it appears in both DS A and DS B . 
If a stream does not appear in DS Ba .., then it appears in D3 M if 
and only if it appears in at least one of the sets D3 A and D3 B . 


1. 

X 

G 

DS 

B>» A X G ds a A X G 

ds b => 

X 

G ds m . 

2 . 

X 

€ 

DS 

B... A G DS a a X 

G D3 b ) 

=> "’(x G ds h ) . 

3. 

—1 

(X 

€ 

A (x G DS a V 

x G ds b 

) 

=5 x G DS„. 

4 . 

-> 

(X 

G 

ds 8 „.) a -*(x G ds a 

v x G ds b ; 

) => -'(X G DS„) 


2. Control Constraint* 

Control constraints are a set of pre-conditions 
which control the firing of particular components, and post¬ 
conditions which determine the output provided by those 
components. The control constraints appear in the change- 
merged operator according to the same rules as the data stream 
definitions. Any control constraint which appears in all 
three input versions in the exact same way will appear in the 
change-merged operator without change. Any operator which 
appears in one or both of the modifications, but not in the 
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base, will appear unchanged as long as the conditions of the 
constraint are the same. Changes in conditions are handled 
differently depending on the type of constraint. Input and 
output guards, and conditional exceptions, "TRIGGERED IF", 
"OUTPUT IF", "EXCEPTION IF", and timer operations have logical 
predicates as conditions. Timer operations are not change- 
merged as straight-forwardly as other predicate c nstraints. 
Different operations exist for different activities. Start, 
stop, read, and reset are the four timer operations used in 
PSDL. The read operation has no effect on the state of the 
timer, so these operations can be merged independently. If a 
read operation appears in all three versions, or appears in at 
least one of the modifcations, but not in the base, then it 
appears in the change-merged version as well. The other timer 
operations do affect the state of the timer. The start and 
stop operations affect the run state of the timer, and the 
reset operation affects the value state of the timer. The 
reset operation is thus independent of the others, and hence 
cna be merged according to the same rules as the read 
operation. The start and stop operations must be change- 
merged using a flat lattice ordering relation, as with inputs 
and outputs. This lattice is 3hown in Figure 33. The 
predicates which accompany the control constraints are change- 
merged according to the usual rule, A[Base]B = (A - Base) U 
(A I I B) LI (B - Base), where the operations IJ, Tl, and - are 
interpreted as follows: 



1. a U b =£> a v b 

2. a I”! b =£ a a b 

3. a - b a a ~'b 


start stop 




Figure 33. Start and Stop Timer Operations are Merged Using a 
Flat Lattice Ordering Relation. 




"PERIOD” and "FINISH WITHIN" have integer values as 
conditions. These values are ordered using a flat lattice and 
can be change-merged in the same way as described for Maximum 
Response Time and Minimum Calling Period. An example of a 
control constraint change-merge is shown in Figure 34. In 
this example, the constraint on A2 does not appear in M 
because it appeared in Base and B, but not in A. The 
constraints on A3 and A4 appear in M because they are not in 
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the base and do appear in one of the modifications. The 
predicate for the constraint on A1 is different in A and B, so 
according to the rule above, the result of the merge is 
calculated as follows: 


y < 0 [ y < 0 ] y > 0 = 

(y < 0 a ~>(y <, 0)) v (y < 0 a y ^ 0) v (y k 0 a “• (y < 0) 
= False v False v (y > 0 a (y > 0) 
= (y > 0) . 

The "READ" operation appeared in the change-merged 
version, because it appeared in one of the modifications, the 
other timer operation did not appear in the merged version, 
because it did appear in the base and in one of the 
modifications, but not in the other. 


C„... = CONTROL CONSTRAINTS 

A1 TRIGGERED IF y < 0 
A2 TRIGGERED BY SOME x 
START TIMER2 IF TRUE 
READ TIMER1 IF z < 0.01 


C A = 

CONTROL CONSTRAINTS 

A1 TRIGGERED IF y > 0 
A3 PERIOD 30 ms 


C B = 

CONTROL CONSTRAINTS 
A1 TRIGGERED IF y < 0 
A2 TRIGGERED BY SOME x 
A4 FINISH WITHIN 20 ms 
START TIMER2 IF TRUE 


C* = CONTROL CONSTRAINTS 

A1 TRIGGERED IF y > 0 
A3 PERIOD 30 ms 
A4 FINISH WITHIN 20 ms 
READ TIMER1 IF z < 0.01 


Figur* 34. Exaopls: A Msrgs of Control Constraints. 
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D. CORRECTNESS OF CHANGE-MERGE OPERATION 

Thus far, we have described a model which provides for 
separate merging of specifications and implementations. We 
have demonstrated that for the individual cases, the model 
either produces a program which is syntactically correct or 
provides evidence to indicate where an inconsistency exists. 
There are still two things that need to be shown. First, we 
must show that the change-merged implementation is consistent 
and correctly implements the change-merged specification. 
Sub-section 1, below, provides a boolean function Imp (Graph, 
Specification) which is true if the interface of Graph 
corresponds to Specification, and a theorem which defines the 
necessary conditions for a consistent change-merge. Secondly, 
we must discuss the semantic properties of our model. These 
are discussed in sub-section 2, below. 

1. Consistency of Model 

In developing our model for the change-merge 
operation, we chose to handle the specifications and 
implementations separately. This is beneficial for developing 
the change-merge model, but requires showing that the 
implementation produced by the change-merge correctly 
implements the change-merged specification. Consistency 
between an implementation and a specification is defined as 
follows: 
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Imp: PSDL Graph X PSDL Spec = ^ > Bool 


Jmp(G A , 


Sp A ) 

X G 

<=> 

i A <=> (x € 

A. S a 

(EXT, x) G A.LI) 

A 

y € 

0 A <=> <y G 

A. S a 

(y, EXT) G A.LO) 

A 

z G 

St A => (z G 

DS a a 

3w G A. V [ ( w, z) 

G A.LI) 



a 3v 

G A. V [ (z, V) G 

A.LO] ) 


This definition states that the graph G A correctly 
implements the specification Sp A if and only if all of the 
following are true: 


1. Ax will appear in the input set of the specification if 
and only if it appears in the set of streams of the graph, 
and there is an edge in the set of input links from 

EXT to x. 

2. Ay will appear in the output set of the specification 
if and only if it appears in the set of streams of the 
graph, and there is an edge in the set of output links from 
y to EXT. 

3. A z will appear in the set of states in the 
specification if and only if it appears in the set of data 
streams of the operator, and there is an operator, w, in the 
set of vertices of the graph such that there is an edge from 
w to z in the set of input links, and there is an operator, 
v, in the set of vertices of the graph such that there is an 
edge in the set of output links from z to v. 


To show that the change-merged implementation is 
consistent with its specification, we provide the theorem in 
Figure 35. This theorem shows that if the three input 
versions are consistent, the change-merged version will be 
consistent. Our proof of this theorem is contained in 
Appendix B. 

2. Semantic Properties of the Model 

The least common extension of two programs provides 
the desired semantics for a merging operation, but as was 
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THEOREM : If Sp A , Sp Ba „ and Sp B are PSDL operator 

specifications, B A , B Baaa and B b are operator graphs, 
lap (B a , Sp A ) , lap (B Baaa , Sp Baa .) and Iflip(B B , Sp B ) , 
then ljnp(B A [B Baa .]B B , Sp A [Sp 

B • • • ] Sp B ) . 

Figure 35. Consistency of Change-merge. 

pointed out in [Ref. 10], this is not computable in the 
general case. We write the partial function computed by an 
operator implementation as F(G A ) . Thus, the partial function 
computed by the resultant implementation of our change-merge 
is F (G m ) . The result of a semantic merge on the three partial 
functions, F (G R ) [F (G Baaa ) ] F (G B ) is written as F M . The ideal 
result for our model is: F (G M ) = F M . This ideal cannot always 
be realized in practice, because F„ is not computable in the 
general case. 

The best result that may be practically realizable 
is: F m C F(G„) . In this situation, the change-merge 

operation produces a result which is compatible with the ideal 
result, but which may contain inconsistent values, T, in some 
cases where an ideal semantic merge produces a proper result. 
The worst acceptable result is: F (B M ) C F M . In this 
situation, the result of the change-merge is also compatible 
with the ideal result, but may diverge in some cases where the 
semantic merge has a proper value. This situation is less 
desirable, because it cannot be detected at merge time. This 
result is the weakest reliable one, which says that the merge 
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produces a correct result whenever it produces a proper 
result. 5 The approximation argument given in [Ref. 10] for 
two input merges is also applicable to change-merges. We have 
discovered that the result of the change-merge is semantically 
correct in most cases, but we have not proved correctness in 
all possible cases, so that complete correctness is not 
guaranteed. We conjecture that the model satisfies the 
property, Vx E Domain (1 * F (G*,) * T) F (G„) (x) = F M (x), 
which is halfway between the best pratically realizable 
situation and the worst acceptable situation. 

E. SUMMARY 

In this chapter, we have described a model for change¬ 
merging PSDL proarams. This model divides the problem into 
three distinct sub-problems and tackles them individually. 
What we have found is that when broken down, these problems 
are relatively simple. Simple set operations are used in most 
cases to perform the change-merge operation. Once the change- 
merge operation is performed, a consistency check can be 
performed to ensure that the change-merged implementation 
accurately represents the change-merged specification. 
Semantically, this model provides a correct merge in most 
cases, but the correct result is not guaranteed. 


’Proper results are normal data values, produced by 
computations that terminate cleanly. 
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IV. CONCLUSION 


Software is always changing. Whether the change is part 
of the normal evolution process, or is necessary to fix a 
problem, it is still a complicated process. The larger 
software systems become, the more complicated making changes 
becomes. 

A. BENEFITS TO SOFTWARE ENGINEERING 

New methods of software development have emerged, such as 
Rapid Prototyping, which require the ability to quickly create 
and adapt a prototype to meet the user's needs. This, in 
turn, makes it necessary to make changes very rapidly. The 
only way to effectively make changes rapidly, especially to 
very large systems, is through automation. 

The need for automatically making changes arises when a 
series of software systems have been developed from a common 
base system, and a change has to be made to the base. If an 
automated way of propagating the change through all the 
versions is available, then the software maintainer will save 
a lot of time, and the end product will probably have fewer 
errors. This thesis has been directed at defining a method 
for doing this automatic change propagation. 
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B. BENEFITS TO CAPS RESEARCH 

The Computer Aided Prototyping System, being developed at 
the Naval Postgraduate School, is a rapid prototyping system. 
The language used in CAPS, PSDL, is very adaptable to 
automatic change propagation. We have developed a model for 
merging three versions of a PSDL program, a base version, and 
two modifications. We call this three input merge operation, 
"change-merging". This model can be used, not only for 
automatically propagating changes through a series of software 
systems, but can be used to combine the characteristics of two 
different software systems, which were developed from a common 
base . 

The model is effective for change-merging different 
versions of a common PSDL program, and we have shown that as 
long as the result of the change-merge is not an 
inconsistency, the merged implementation will correctly 
represent the merged specification. The semantic result of 
the change-merge has been shown to be correct most of the 
time. 

This model theoretically provides the ability for the 
engineer writing a prototype, or a series of prototypes, to 
develop a change to the base version and press a button to 
invoke the merging mechanism to automatically update all 
versions of the system. It can also be used to automatically 
update a series of prototypes in the software base, developed 
from a common base. 
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C. FURTHER RESEARCH 

In this thesis, we have provided a model on which the 
change-merger can be based for programs written in PSDL. Our 
work leads to a method that produces correct results most of 
the time, but the degree of correctness has not been formally 
established. Future work should classify the results by how 
close they come to an ideal semantic merge, suggest stronger 
approximations that produce results even closer to the ideal 
semantic merge, and prove the partial correctness of the 
results. 

Eventually, an attempt should be made to develop a 
change-merger for Ada code, so that data types and PSDL 
operators implemented in Ada code can be included in the 
change-merger. For the change-merger to become a reality as 
currently modelled, a high level language description and 
specification must be developed, and eventually, the program 
must be coded in a programming language such as Ada. 
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APPENDIX A. PSDL GRAMMAR 


This grammar uses standard symbology conventions. {Curly 
Braces} enclose items which may appear zero or more times. 
[Square Brackets] enclose items which may appear zero or one 
time. Bold Face items are terminal keywords. Items contained 
in "Double Quotes" are character literals. The "|" vertical 
bar indicates a list of options from which no more than one 
item may be selected. This grammar represents the current 
version of the PSDL grammar as of 20 June 1990. 

Start = psdl 
psdl = {component} 
component = data_type | operator 
data_type = type id type_spec type__impl 
operator = operator id operator_spec operator_impl 
type_spec = specification [generic_param] [type_decl] 
{operator id operator_spec} [functionality] end 
type_impl = implementation ada id "{" text "}" end 
| implementation type_name 
{operator id operator_impl} end 
operator_spec = 

specification {interface} [functionality] end 
operator_impl = implementation ada id "{" text "}" 

| implementation psdl_impl 
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type_decl = 

id_list type_name id_list type_name} 

functionality = [keywords] [informal_des'] [formal_desc] 

psdl_impl = data_flow_diagram [streams] [timers] 
[control_constraints] [iniormal_desc] end 
type_name = id | 

id "[" actual_parameter_list "]" | 
id "[" type_decl "]" 

actual_parameter_list = actual_parameter 

{ actual_parameter } 

actualjparameter = type_name i expression 

interface = attribute [reqmts_trace] 

id_list = id id} 

keywords = keywords id_list 

informal_desc = description "{" text 

formal_desc = axioms "{" text ” 

data_flow_diagram = graph {vertex} {edge} 

streams = data stream type_decl 

timers = timer id_xist 

attribute = input 
I output 
I generic_param 
I states 
I exceptions 
I timing_info 

input = input type_decl 

output = output type_decl 

generic^param = generic type decl 

states = states type_decl initially expression list 
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exceptions = exception* id_list 

timing_info = [maximum execution time time] 

[minimum calling period time] 

[maximum response time time] 

reqmts_trace = by requirements id_list 

vertex = vertex op_id [”:’’time] 

edge = edge id [":"time] op_id op__id 

op_id = id t"(" [id_list] "|" [id_list] ")"] 

control_constraints = control constraints {constraint} 

constraint = operator id 

[triggered (trigger | [trigger] if predicate) 

[reqmts_trace]] 

[period time [reqmts_trace]] 

[finish within time [reqmts_trace]] 

{constraint_options} 

trigger = by all id_list 
| by some id__list 

constraint_options = 

output id_list if predicate [reqmtsjtrace] 

| exception id [if predicate] [reqmts_trace] 

I timer_op id [if predicate] [reqmts_trace] 

timer_op = read timer 
| reset timer 
| start timer 
I stop timer 

expression_list = expression expression} 

time = integer [unit] 

unit = ms | sec | min | hours 

expression = constant 
I id 

| type_name id expression_list ")" 

predicate = simple__expression 

| simple_expression rel_op simple expression 







simple_expression = [sign] integer [unit] 
i [sign] real 
! [not] id 
| string 

| [not] "(" predicate ")" 

| [not] boolean_constant 

bool_op = and | or 

rel__op = "<" | "<=" | ">" | ">=" | " = " | "/ = " | 

real = integer "." integer 

integer = digit{digit} 

boolean_constant = true | false 

numeric_constant = real | integer 

constant = numeric_constant j boolean_constant 

sign = "+" | 

char = any printable character except "}" 

digit = "0 .. 9" 

letter = "a .. z” | "A .. Z" | 

alphanumeric = letter | digit 

id = letter {alphanumeric } 

string = .. text """ 

text = {char} 
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APPENDIX B. PROOF: CONSISTENCY OF CHANGE-MERGE THEOREM 


This appendix contains the proof of our Consistency of 
Change-merge theorem in Chapter III, Figure 35. 

PROOF : 

Let M = A[Base]B be the result '.nt operator after a 
change-merge operation. 

Assume: Iap(G A , Sp A ) , Xnqp(G B ..., Sp B „.) and Xinp(G B , Sp B ) . 

Need to Show: Jmp(G M , Sp M ) . 


Assume x G I M , y 

G 

0 M , 

and 

z G st M 



Need to Show A. 

(-•< 

G 

M.S a 

(EXT, x) 

G 

M.LI) 

B. 

(y 

G 

M.S a 

(y,EXT) 

G 

M.LO) 

C . 

(Z 

G 

ds m a 

3 w G m . 

V 

[ (w, z) G M.LI] 


a 3v G M.V [( z,v) G M.LO] 


A. There are two possibilities: x G I Ba , # and “Mx G I Bs ,.) . 
Case 1 : x G I B „. 

Then by definition of change-merge, x G I A a x G I b . 

Since Imp( G B ..., Sp B .„) , Iap(G A , Sp A ) and Imp(G B , Sp B ) , 

Then x G Base.S a (EXT,x) G Base.LI) a 

x G A . S a (EXT , x) G A.LI) a 

X G B.S A (EXT, x) G B.LI) 

And by definition of change-merge 

x G M.S a (EXT, x) G M.LI) (A.) 







Case 2: 


“•U € i B „.) 


Then by definition of change-merge, x G I A ✓ x G I B . 

Since X«p(G B .„, Sp B „.) , Xjqp(G A , Sp A ) and Xmp(G B , Sp B ) , 

Then (x G Base.S a (EXT,x) G Base.LI)) a 
(( x G A.S a (EXT,x) G A.LI) v 
(x G B.S a (EXT,x) G B . LI)) 

Since (EXT, x) G Base.LI x G Base.S 

Then x G Base.S a (EXT,x) G Base. LI 
(EXT, x) G Base.LI 

Thus "• (x G Base.S a (EXT,x) G Base.LI)) < i = i> 
“ 1 (EXT,x) G Base. LI 

Thus (EXT , x) G A.LI v (EXT,x) G B.LI 

And x G A.S . x G B.S 

And by definition of change-merge 

x G M.S a (EXT,x) G M.LI) (A.) 

B. There are two possibilities: y G 0 B „. and (y G 0 B .,J 
Case 1 : y G 0 B .„ 

Then by definition of change-merge, y G 0 A / y G 0 B . 

Since Xxz^p Sp B .„) , Xfl¥>(G A , Sp A ) and Imp ( G B , Sp B ) , 

Then y G Base.S a (y, EXT) G Base.LO) a 
y G A.S a (y, EXT) G A.LO) a 

y G B.S a (y, EXT) G B.LO) 

And by definition of change-merge 

y G M.S a (y, EXT) G M.LO) (B.) 
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Case 2: (y G 0 B .„) 

Then by definition of change-merge, y G 0 A v y G 0 B . 

Since Xinp(G B ..., Sp B ..J , Xap(G x , Sp x ) and X«p(G B , Sp„) , 

Then “My G Base.S a (y,EXT) G Base.LO)) a 
((y G A.S a (y,EXT) G A.LO) v 
(y G B.S a (y,EXT) G B.LO)) 

Since (y, EXT) G Base.LO => y G Base..- 

Then y G Base.S a (y, EXT) G Base.LO < t = r > 

(y,EXT) G Base.LO 

Thus (y G Base.S a (y,EXT) G Base.LO)) 

“My, EXT) G Base.LO 

Thus (y,EXT) G A.LO ✓ (y,EXT) G B.LO 

And yG A.S v y G B.S 

And by definition of change-merge 

y G M.S a (y,EXT) G M.LO) (B.) 

C. There are two possibilities: z G St B „. and ( z G St Bll ,.) . 

Case 1: z G St B ... 

Then by definition of change-merge, z G St x ' z G St B . 

Since XxBp(G B .„, Sp B .„) , XayiG*, Sp x ) and Imp(G B , Sp B ) , 

Then (z G DS Ba „ a 3w G Base.V [(w, z) G Base.LI] 

a 3v G Base.V [{z, v ) G Base.LO]) a 
( z G DS X a 3w G A.V [ ( w, z) G A.LI] 

a 3v G A.V [(z, r) G A.LO]) a 
(z G DS b a 3k G B.V [(w, z) G B.LI] 
a 3v G B.V [(z, v) G B.LO]) 
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And by definition of change-merge 

(z G DS m a 3w G M.V [(w, z) G M.LI] 

A 3v G M.V [(z, v) G M . LO ] ) (C.) 


Case 2: 


<z G St B ..J 


Then by definition of change-merge, z G St A v z G St B 

Since Jjap(G Ba „, Sp B .„) , Zmp(G k , Sp A ) and Imp(G B , Sp B ) , 

Then “’(z G DS B ,„ a 3w G Base.V [(w, z) G Base.LI] 

a 3v G Base.V [ (z, v) G Base.LO]) 
((z G DS a A 3w G A.V [ (w, z) G A.LI] 

a 3v G A.V [(z, v) G A.LO]) . 

(z G DS b a 3w G B.V [(w, 2 ) G B.LI] 

A 3v G B.V [(z, v) G B. LO] ) ) 

And by definition of change-merge 

(z G DS m a 3w G M.V [ (w, z) G M.LI] 

a 3v G M.V [(z, v) G M. LO ] ) (C.) 

Therefore by A, B, and C we conclude 

x G I M => U G M.S • (EXT, x) G M.LI) .- 
y G 0 M (y G M.S a (y, EXT) G M.LO) a 

z G St M —^ (zG DS m a3wG M.V [(w, z) G M.LI] 

A 3v G M.V [( z, r ) G M.LO] 




Assume (x G M.S a (EXT, x) G M.LI) and 
(y G M.S a (y, EXT) G M.LO) 

Need to Show D. x G I M 
E. y G 0 M 
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D. There are two possibilities: 

x E Base.S a (EXT,x) E Base.LI and 
“Mx E Base.S a (EXT,x) E Base.LI). 

Case 1: x E Base.S a (EXT,x) E Base.LI 

Then by definition of change-merge, 
x E A.S a (EXT,x) E A.LI a 
x E B.S a (EXT,x) E B.LI 

Since lap (G B .„, Sp B ..J , Imp (G A , Sp A ) and lap (G„, Sp B ) , 

* £ I s... a x E I A A x E I B 

And by definition of change-merge, x E I M . (D . ) 

Case 2: “* (x E Base.S a (EXT,x) E Base.LI) 

Since (EXT,x) E Base.LI x E Base.S 

Then x E Base.S a (EXT,x) E Base.LI 
(EXT, x) E Base. LI 

Thus ”*(x E Base.S a (EXT,x) E Base.LI)) <£=> 
“»(EXT,x) E Base.LI 

Thus (EXT,x) E A.LI v (EXT,x) E B.LI 

And xE A.SvxE B.S 

Then x E A.S a (EXT,x) E A.LI v 
x E B.S a (EXT,x) E B.LI 

Since Imp (G„..., Sp B ...) , Jap(G A ,Sp A ) and Imp (G,, Sp B ) , 

“•(x E I B „.) a (x E I A v x E I B ) 

And by definition of change-merge, x E I M . (D.) 
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E. There are two possibilities: 

y G Base.S a (y,EXT) G Base.LO and 
“My G Base.S a (y, EXT) G Base.LO). 

Case 1: y G Base.S a (y,EXT) G Base.LO 

Then by definition of change-merge, 
y G A.S a (y, EXT) G A.LO a 
y G B.S a (y, EXT) G B. LO 

Since lap Sp 8 „.) , Jatp <G X , SpJ and Jap <G„ Sp B ) , 

y ^ I s... a y G I* a y G I, 

And by definition of change-merge, y G I M . (E.) 

Case 2: “My £ Base.S a (y, EXT) G Base.LO) 

Since (y,EXT) G Base.LO y G Base.S 

Then y G Base.S (y, EXT) G Base.LO <£=> 

(y,EXT) G Base.LO 

Thus “My G Base.S a (y,EXT) G Base.LO)) <=> 

“ 1 (y,EXT) G Base.LO 

Thus (y,EXT) G A.LO v (y, EXT) G B . LO 

And y G A.S </- y G B.S 

Then y G A.S a (y,EXT) G A.LO - 
y G B.S a (y,EXT) G B . LO 

Since lap (G B .„, Sp 8 ...) , lap (G*, Sp A > and Jap(G B , Sp B ) , 

” , (y € I B ..J A (y G I, V y G I B ) 

And by definition of change-merge, y G 1 M . (E.) 
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Therefore by D and E we conclude 

(x G M.S a (EXT, x) G M.LI) x G I M a 

(y G M.S a (y, EXT) G M.LO) => y G 0 M 

Therefore By ( = $) and C^), Iaip(G M , Sp M ) . D 
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GLOSSARY 


Approximates - A program P approximates another program Q if 
P is defined everywhere that Q is defined. Q may or may not 
be defined in places where P is undefined. 

Bipartite - A bipartite graph is a graph in which the 
vertices can be divided into distinct sets, where there exists 
no edge from one vertex to another within the same set. 

Computer-Aided Prototyping System(CAPS) - This system is 
being developed by Dr. Berzins and Dr. Luqi at the Naval 
Postgraduate School for use in Rapid Prototyping of Real-Time 
Systems. 

CPU - Central Processor Unit 

Directed Acyclic Graph(DAG) - It is a graph which contains 
directed edges and no cycles. 

Feasible - Any PDG G p is feasible if it is a PDG for a 
program P. The slice G/S is feasible if S c V(G) and G is 
feasible. 

FIFO - First In First Out. 

Greatest Common Approximation - The greatest common 
approximation of two programs is considered to be a program 
which approximates both programs and contains all of the 
functionality common to both programs. 

Least Common Extension - The least common extension of two 
programs is the result of merging the functionality contained 
in both programs. Both input programs approximate the least 
common extension. 

Program Dependence Graph(PDG) - Used by Horwitz et al. to 
abstractly represent programs. It consists of a set of 
vertices and a set of edges which link these vertices. The 
vertices represent operations performed in the program, and 
the edges represent control flow and data flow dependences 
between those operations. 

Prototyping System Description Language(PSDL) - Rapid 
prototyping language developed by Dr. Luqi at the Naval 
Postgraduate School for use in designing prototypes within the 
CAPS system. 







Software Maintenance - All activities performed on a software 
system during its life time to enhance or repair the system. 

Software Manufacture - The combining of primitive components 
of a software system, through a sequence of derivations, into 
one or more software products. 
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